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EFFICIENT AND SECURE AUTHENTICATION OF COMPUTING SYSTEMS 
BACKGROUND OF THE INVENTION 

1. The Field of the Invention 

[0001] The present invention relates to extensible authentication and credential 
provisioning. More specifically, the present invention relates to automated negotiation of 
authentication mechanisms and limited-use credentials that can be used to provision 
additional credentials. 

2. Background and Related Art 

[0002] Computer systems and related technology affect many aspects of society. 
Indeed, the computer system's ability to process information has transformed the way we 
live and work. Computer systems now commonly perform a host of tasks (e.g., word 
processing, scheduling, and database management) that prior to the advent of the computer 
system were performed manually. More recently, computer systems have been coupled to 
one another to form computer networks over which the computer systems can communicate 
electronically to share data. As a result, many of the tasks performed at a computer system 
(e.g., accessing electronic mail and web browsing) include electronic communication with 
one or more other computer systems via a computer network (e.g., the Internet) 
[0003] In order for one computer system to communicate electronically with another 
computer system, the computer system, as well as a corresponding computer system user, 
may need to authenticate with (i.e., prove its identity to) the other computer system (or a 
computer system that authorizes access to the other computer system. Depending on the 
environment, any of a wide variety of different computerized authentication mechanisms, 
such as, for example, Kerberos, Secure Sockets Layer ("SSL"), NT LAN Manager 
("NTLM"), and/or Digest authentication, can be used. 
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[0004] Some authentication mechanisms include an interactive logon. For example, 
before a computer system can communicate electronically on the Internet, a user of the 
computer system is often required to log-in with an Internet Service Provider (hereinafter 
referred to as an "ISP") that can authorize access to the Internet. Logging-in with an ISP 
typically includes a submission of user credentials (e.g., a username and a password) from 
the computer system to the ISP. Upon receiving the credentials, the ISP compares the 
credentials to a credentials database and if the credentials are appropriate the computer 
system is authorized to communicate with the Internet. 

[0005] Unfortunately, there is always some risk of unauthorized users obtaining an 
authorized user's credentials and using the credentials to impersonate the authorized user. 
Since an authorized user's credentials essentially allow full access to all of authorized users 
resources on a particular system (e.g., files, electronic messages, personal and financial data, 
etc.), any comprise in credentials can provide an unauthorized user with the ability to copy 
and destroy the authorized user's resources. In particular, passwords are vulnerable to 
guessing attacks, for example, from programs that sequentially submit each word in a 
dictionary as a password (commonly referred to as "dictionary attacks"). 
pi [0006] Other authentication mechanisms do not include an interactive logon and thus 
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^ " automatically sending a digital certificate that authenticates the Web server. The Web client 

generates a unique session key to encrypt all communication with the Web server. The Web 
client encrypts the session with the Web server's public key (e.g., referenced in the 
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certificate) so only the Web server can read the session key. Thus, a secure session is 
established without requiring any user actions. 

[0007] Although examples of interactive authentication and non-interactive 
authentication mechanisms have been described, it should be understood that 
implementations of interactive authentication and non-interactive authentication can vary 
between networks and computer systems. For example, one network may be configured to 
use Kerberos authentication, while another network is configured to use some other 
interactive authentication mechanism. Further, a particular authentication mechanism can 
have different configuration options that cause the authentication mechanism to operate 
differently. For example, some implementations of SSL allow different encryption 
algorithms to be selected when establishing a secure session. 

[0008] Unfortunately, it can be difficult or even impossible, to determine the 
authentication mechanism and/or configuration options a computer system or network has 
deployed. Thus, one computing system may attempt to authenticate with another computer 
system using an authentication mechanism and/or configuration option that is not deployed 
at the other computer system. As a result, authentication can fail and prevent the computing 
systems from communicating. 

[0009] The potential for attempting to authenticate using an undeployed authentication 
mechanism is especially high in distributed systems. Distributed systems often include a 
number of interconnected computer systems and networks, where various portions of the 
distributed system are under the control of different entities. These different entities may 
each deploy different authentication mechanisms and may not necessarily advertise or 
publish an indication of the authentication mechanisms that are deployed. Thus, a first 
component of the distributed system may be prevented from authenticating with a second 
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component of the distributed system because the first component does not know (and may 
have no way to determine) the authentication mechanisms deployed at the second 
component. 

[0010] Other authentication problems can occur in wireless environments. For example, 
for a device to wirelessly authenticate with a mixed wired/wireless network, the device may 
be required to a have a certificate corresponding to the network. However, the network may 
be configured to allow only authenticated devices to access the certificate. Thus, the device 
may be required to initially connect to the network via a wired connection. Requiring a 
wired connection for access to a certificate can burden a user (e.g., a user may need to locate 
a network tap) and in some environments may be difficult (e.g., network taps may be in 
restricted access location) or even impossible (e.g., some devices are not configured for 
wired network access). Accordingly, even authorized users may be prevented from 
wirelessly accessing a network. 

[0011] Therefore, what would be advantageous are mechanisms for automatically 
negotiating authentication methods and more securely provisioning of credentials. 
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BRIEF SUMMARY OF THE INVENTION 
[0012] The foregoing problems with the prior state of the art are overcome by the 
principles of the present invention, which are directed to more efficiently and securely 
authenticating computing systems. In some embodiments, a client computing system 
receives a limited-use credential. The client computing system and a server computing 
system establish a secure link between one another. The client computing system submits 
the limited-use credential to the server computing system over the established secure link. 
[0013] The server computing system receives the limited-use credential from the client 
computing system over the established secure link. The server computing system provisions 
an additional credential for the client computing system based on the received limited-user 
credential. The server computing system sends the additional credential to the client 
computing system over the established secure link. The client computing system receives 
the additional credential from the server computing system. Optionally, the client 
computing system subsequently uses the received additional credential to authenticate with 
the server computing system. 

[0014] In other embodiments, a server sends first request that includes at least the 
authentication mechanisms deployed at the server computing system. The client receives 
the first request and sends a first response that includes at least the authentication 
mechanisms deployed at the client computing system. The client and server identify a 
tunnel key that can be used to encrypt content transferred between the client computing 
system and server computing system. 

[0015] The sever sends a second request that includes encrypted authentication content 
(encrypted with the tunnel key) indicating a mutually deployed authentication mechanism. 
The client receives the second request and decrypts the encrypted authentication content 
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with the tunnel key to reveal unencrypted authentication content. The unencrypted 
authentication content indicating the mutually deployed authentication mechanism. The 
client sends a second response including encrypted response data that is the response to the 
unencrypted authentication content. The encrypted response data contains information for 
authenticating with the server according to the mutually deployed authentication 
mechanism. The server receives the second response including the encrypted response data 
that contains information for authenticating with the server according to the mutually 
deployed authentication mechanism. 

[0016] Additional features and advantages of the invention will be set forth in the 
description that follows, and in part will be obvious from the description, or may be learned 
by the practice of the invention. The features and advantages of the invention may be 
realized and obtained by means of the instruments and combinations particularly pointed out 
in the appended claims. These and other features of the present invention will become more 
fully apparent from the following description and appended claims, or may be learned by the 
practice of the invention as set forth hereinafter. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[0017] In order to describe the manner in which the above-recited and other advantages 
and features of the invention can be obtained, a more particular description of the invention 
briefly described above will be rendered by reference to specific embodiments thereof which 
are illustrated in the appended drawings. Understanding that these drawings depict only 
typical embodiments of the invention and are not therefore to be considered to be limiting of 
its scope, the invention will be described and explained with additional specificity and detail 
through the use of the accompanying drawings in which: 

[0018] Figure 1 illustrates example computer architecture that facilitates more efficient 
and secure authentication of a computing system in accordance with the present invention. 
[0019] Figure 2 illustrates a flowchart of an example method for provisioning 
credentials in accordance with the present invention. 

[0020] Figure 3 illustrates a message exchange for automatically negotiating 
authentication methods. 

[0021] Figure 4 illustrates a suitable operating environment for implementing the 
principles of the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0022] The principles of the present invention relate to systems, methods, and computer 
program products for more efficiently and securely authenticating computing systems. 
Embodiments within the scope of the present invention include computer-readable media for 
carrying or having computer-executable instructions or data structures stored thereon. Such 
computer-readable media may be any available media, which is accessible by a general- 
purpose or special-purpose computing system. By way of example, and not limitation, such 
computer-readable media can comprise physical storage media such as RAM, ROM, 
EPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic 
storage devices, or any other media which can be used to carry or store desired program 
code means in the form of computer-executable instructions, computer-readable instructions, 
or data structures and which may be accessed by a general-purpose or special-purpose 
computing system. 

[0023] In this description and in the following claims, a "network" is defined as one or 
more data links that enable the transport of electronic data between computing systems 
and/or modules. When information is transferred or provided over a network or another 

g communications connection (either hardwired, wireless, or a combination of hardwired or 
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w 5 < % §j x wireless) to a computing system, the connection is properly viewed as a computer-readable 
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§ BE 1 1 < Combinations of the above should also be included within the scope of computer-readable 
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media. Computer-executable instructions comprise, for example, instructions and data 
which cause a general-purpose computing system or special-purpose computing system to 
perform a certain function or group of functions. The computer executable instructions may 



< 



- Page 9 - 



Docket No. 13768.497 



be, for example, binaries, intermediate format instructions such as assembly language, or 
even source code. 

[0024] In this description and in the following claims, a "computing system" is defined 
as one or more software modules, one or more hardware modules, or combinations thereof, 
that work together to perform operations on electronic data. For example, the definition of 
computing system includes the hardware components of a personal computer, as well as 
software modules, such as the operating system of the personal computer. The physical 
layout of the modules is not important. A computing system may include one or more 
computers coupled via a network. Likewise, a computing system may include a single 
physical device (such as a mobile phone or Personal Digital Assistant "PDA") where 
internal modules (such as a memory and processor) work together to perform operations on 
electronic data. 

[0025] As used herein, the term "module" or "component" can refer to software objects 
or routines that execute on the computing system. The different components, modules, 
engines, and services described herein may be implemented as objects or processes that 
execute on the computing system (e.g., as separate threads). While the system and methods 
described herein are preferably implemented in software, implementations in software and 
hardware or hardware are also possible and contemplated. 

[0026] Those skilled in the art will appreciate that the invention may be practiced in 
network computing environments with many types of computing system configurations, 
including, personal computers, laptop computers, hand-held devices, multi-processor 
systems, microprocessor-based or programmable consumer electronics, network PCs, 
minicomputers, mainframe computers, mobile telephones, PDAs, pagers, and the like. The 
invention may also be practiced in distributed system environments where local and remote 
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computing systems, which are linked (either by hardwired data links, wireless data links, or 
by a combination of hardwired and wireless data links) through a network, both perform 
tasks. In a distributed system environment, program modules may be located in both local 
and remote memory storage devices. 

[0027] Figure 1 illustrates example computer architecture 100 that facilitates more 
efficient and secure authentication of a computing system in accordance with the present 
invention. As depicted in computer architecture 100, client computing system 101 includes 
key pair 103. Key pair 103 includes public key 104 and corresponding private key 106, for 
example, a Diffie-Hellman key pair. Server computing system 111 includes credential 
provisioning module 112 and key pair 113. Credential provisioning module 112 can be 
configured to receive a first type of credential, such as, for example, a limited-use credential, 
and, based the first type of credential, provision a second type of credential, such as, for 
example, a more permanent credential. Similar, to key pair 103, key pair 113 includes 
public key 1 14 and corresponding private key 1 16, for example, a Diffie-Hellman key pair. 
[0028] Figure 2 illustrates a flowchart of an example method 200 for provisioning 
credentials in accordance with the present invention. The method 200 will be described with 

pi respect to the computing systems and modules in computer architecture 100. The method 
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a B 1 1 S 5 [0029] The use of a limited-use credential can be limited in any number of ways. For 
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^ " example, limited-use credential can be valid for specified number of uses, for a specified 
period of time, or until the occurrence of a specified event. A limited-use credential can be 
limited to any number of valid uses (e.g., three uses), based on applicable security policies. 
Limited-use credentials that are valid for authenticating only once may be referred to as 
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"single-use credentials". After the specified numbers of uses, the limited-use credential is 
no longer accepted as a valid credential. 

[0030] A limited-use credential can be limited to any specified time period (e.g., five 
minutes), based on applicable security policies. After a specified time period expires, the 
limited-use credential is no longer accepted as a valid credential. Any specified event can 
limit the use of a limited-use credential, based on applicable security policies. For example, 
a limited-use credential can be rejected after more permanent credentials are provisioned. 
[0031] A limited-use credential can be received out-of-band via communication 
methods, such as, for example, telephonic communication or mail. Alternately, trusted 
computerized communication methods can also be used to receive a limited-use credential 
(e.g., encrypting the limited-use credential in an electronic mail message). 
[0032] The method 200 includes an act of a client side establishing a secure link (act 
202) and a server side establishing a secure link (act 205). For example, client computing 
system 101 and server computing system 111 can establish secure link 122. Establishment 
of a secure link can include client computing system 101 and server computing system 111 
exchanging public keys to establish a session key. For example, public key 104 and public 
key 114 can be exchanged to establish session key 131. In some embodiments, 
establishment of a session key may be enough for subsequent authentication, such as, for 
example, when client computing system 101 and server computing system 111 are 
configured with static Diffie-Hellman keys. 

[0033] Alternately, other keys can be derived to provide other proof. For example, in 
response to a challenge from a server computer system, a client computing system can 
encrypt a password using an encryption key derived from the Diffie-Hellman session key 
and the password and send the encryption key the server computer system. Accordingly, 
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when the server computing system receives the encrypted password, the server computing 
system can decrypt the password and compare the password to a credential database to 
determine if the password is valid. 

[0034] Similarly, a client computing system can encrypt a trust anchor using an 
encryption key derived from a shared secret and the Diffie-Hellman session key and send 
the encrypted trust anchor to a server computing system. Accordingly, when the server 
computing system receives the encrypted trust anchor, the server computing system can 
decrypt and validate the trust anchor. A trust anchor include authentication related data, 
such as, for example, a certificate, (e.g., an X.509 certificate), a security token (e.g., a WS- 
Security token), a hash (e.g., SHA-1) and Uniform Resource Identifier ("URI") (e.g., a 
Uniform resource Locator ("URL")) of a certificate, or a hash and URI of a security token. 
[0035] Likewise, a client computing system can send a new trust anchor that is signed 
with or includes a digest of a previously established trust anchor. Accordingly, the server 
computing system can validate the new trust anchor based on the signature or hash of the 
previously established trust anchor. 

[0036] Referring back to Figure 2, the method 200 includes an act of submitting the 
limited-use credential over the established secure link (act 203). For example, client 
computing system 101 can submit limited use credential 102 to sever computer system 111 
over secure link 122. As previously described, an encryption key derived from the Diffie- 
Hellman session key and a password can be used to encrypt the password. Thus, it may be 
that limited-use credential 102 is encrypted using an encryption key derived from session 
key 131 and limited-use credential 102. 

[0037] The method 200 includes an act of receiving a limited-use credential over the 
established secure link (act 206). For example, server computing system 111 can receive 
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limited-use credential 102 from client computing system 101 over secure link 122. Also, in 
response to a previous request, server computing system 111 can receive an encryption key 
(e.g., used to encrypt limited-use credential 102) from client computing system 101. 
[0038] The method 200 includes an act of provisioning an additional credential for the 
client based on the received limited-use credential (act 207). For example, credential 
provisioning module 112 can provision a more permanent credential (or credentials) for 
client computing system 101 based on limited-use credential 102. When appropriate, server 
computing system 111 can decrypt limited-use credential 102 using a previously received 
encryption key. 

[0039] Credential provisioning module 112 can compare limited-use credential 102 to a 
credential database to determine if limited-use credential 102 is valid. When limited-use 
credential 102 is not valid, server computing system 111 may terminate processing of 
limited-use credential 102. Depending on security policies, server computing system 111 
may or may not notify client computing system 101 that processing of limited-use credential 
102 was terminated. On the other hand, when limited-use credential 102 is valid, there is 
increased reliability in the identity of client computing system 101. Accordingly, server 
& computing system can generate a more permanent credential (or credentials) for client 
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wis! ^§3 1 computing system 101. For example, credential provisioning module 112 can generate 
^ d > 5 1 i: additional credential 117. 
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[0040] Additional credential 117 can be the same type of credential as limited-use 
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^ " credential 102. For example, in response to receiving an appropriate single-use password, 
server computing system 1 1 1 can issue a more permanent password. Alternately, additional 
credential 117 can be a different type of credential. For example, in response to receiving an 
appropriate single-use password, server computing system 111 can issue a certificate, a 
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token (e.g., a WS-Security token or Kerberos token), a hash and URI of a certificate, or a 
hash and URI of a token. 

[0041] Other credential supporting data, such as, certificate chains, certificate revocation 
list, online certificate status protocol responses, WS-security tokens, and metadata that is to 
be associated with an exchange, can also be identified. Identified metadata can include 
extensible Mark-up Lanuage ("XML") instructions. 

[0042] The method 200 includes an act of sending an additional credential (act 208). 
For example, server computing system 111 can send additional credential 117 to client 
computing system 101. The method 200 includes an act of receiving an additional 
credential (act 204). For example, client computing system 101 can receive additional 
credential 117 from server computing system 111. 

[0043] Accordingly, embodiments of the present invention can facilitate access to a 
network when access might otherwise be prevented. For example, a limited-use (or single- 
use) credential can be utilized by a wireless computing system to facilitate access to a 
certificate used for wirelessly accessing a network. Further, limited-use credentials can 
reduce computing system vulnerability to dictionary attacks. For example, a limited-use 
Pi credential may no longer be valid at the time a malicious user eventually cracks the limited- 
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w mechanisms. In should be understood that message exchange 300 can occur before or after 
the exchange of other messages during authentication. For example, a client computing 
system and server computing system can exchange one or more Extensible Authentication 
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Protocol ("EAP") request/response pairs that preliminarily identify the client computing 
system and server computing system to one another. 

[0045] The requests and responses depicted in message exchange 300 can be messages 
of an authentication protocol. Each message can includes the version number of the 
authentication protocol (e.g., representing supported payload types), a message body, and a 
Hashed Message Authentication Code ("HMAC") of a portion of the message body. An 
HMAC can be generated using any cryptographic hash function, such as, for example, MD5, 
SHA-1, etc. The messages of the authentication protocol can be embedded within EAP 
messages. 

[0046] Server side 360 can send server request 301 to client side 305. Server request 
301 includes previous packet ID 302, nonce 303, and authentication methods 304. Previous 
packet ID 302 can indicate the packet ID corresponding to the last packet that was 
exchanged between client side 350 and server side 360 (e.g., the packet ID of packet in a 
previous request/response exchange). Nonce 303 can be random data generated at server 
side 360. Authentication methods 305 can include the proposed authentication mechanisms 
supported at server side 360. A server side can support any number of different 
q6 authentication mechanisms (e.g., challenges and responses as previously described, MS- 

w^<||s CHAP v2, Authentication with MD5, Authentication with Generic Token Card, 
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^d>o5£ Authentication with Kerberos, Authentication with X.509, and Authentication with WS- 
ligfii Security) 

^ " [0047] In response to server request 301, client side 350 can send client response 306 to 

server side 306. Client response 306 can include previous packet ID 307, nonce 308, 
security association(s) 309, public key(s) 311, and authentication methods 312. Previous 
packet ED 307 can indicate the packet ED corresponding to server request 301. Nonce 308 
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can be random data generated at client side 360. Security Associations(s) 309 can include 
proposed security associations that are supported at client side 350. Table 1 indicates some 
of the security associations that can be supported. 



128bit AES CBC Mode 
Diffie-Hellman Group 2 (1024 bit) 
SHA-1 + HMAC 

SHA-1 Hash 

128bit AES CBC Mode 
Diffie-Hellman Group 5 (1536 bit) 
SHA-1 + HMAC 

SHA-1 Hash 

128bit AES CBC Mode 
Diffie-Hellman Group 14 (2048 bit) 
SHA-1 + HMAC 

SHA-1 Hash 

128bit AES CBC Mode 

ECC Diffie-Hellman Group 4 (185 bit) 

SHA256 HMAC 

SHA256 Hash 



Table 1 



[0048] Public key(s) 311 can include one or more public keys. Public key(s) 311 can 
include a key of an appropriate length (e.g., 1024 bits, 2048 bits, etc.) for each supported 
security association. Public keys(s) 311 can be one more Diffie-Hellman public keys 
including, for example, public key 104. Authentication methods 312 can include 
authentication mechanisms supported at client side 350 and selected from among the 
authentication mechanisms included in authentication methods 304. 

[0049J In response to client response 306, server side 360 can send server request 313. 
Server request 313 can include previous packet ID 314, security association 316, public key 
317, and other authentication data based on the authentication method. Previous packet ID 
314 can indicate the packet ID corresponding to client response 306. Security association 
316 can indicate a security association supported at server side 360 and selected from among 
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the authentication methods included in security association(s) 309. Public key 317 can be a 
key of appropriate length for the security association indicated in security association 316. 
Public key 317 can be a Diffie-Hellman public key, such as, for example, public key 1 14. 
[0050] Accordingly, based on the appropriate length key from public key(s) 311 and 
public key 317, a secure link can be established between client side 350 and server side 360. 
[0051] Generally, encrypted data sent between client side 350 and server side 360 is 
encrypted using a tunnel key. The tunnel key can be derived by hashing the concatenation 
of a Diffie-Hellman shared secret (e.g., session key 131) together with client and server 
nonces. For example, a tunnel key can be derived according to the following formula: 

Tunnel Key = HASH [DH SS + N c + N s ] 
[0052] A tunnel key can be a symmetric key. That is the tunnel key can be used to 
decrypt encrypted data that was encrypted using the tunnel key. Accordingly, client side 
350 can encrypt data that is to be sent to server side 360 with the tunnel key and can decrypt 
content received from the server side 360 with the tunnel key. Similarly, server side 360 can 
encrypt data that is to be sent to client side 350 with the tunnel key and can decrypt content 
received from client side 350 using the tunnel key. 

[0053] When client side 350 and server side 360 are performing a negotiation, server 
request 313 can include negotiation encrypted content 318. Negotiation encrypted content 

318 can include challenge 319, authentication method 321, and trust anchor 322. Challenge 

319 can be an HMAC of the previous packet ID (e.g., previous packet ID 314) using a 
shared secret (e.g., session key 131). For example, challenge 319 can be configured 
according to the following formula: 

Challenge = HMAC ss [PPid] 
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[0054] Server side 360 can maintain an appropriate response to the challenge. For 
example, an appropriate response can be the HMAC of the challenge using the shared secret. 
An appropriate response can be configured according to the following formula: 

Responses = HMAC SS [Challenge] 
[0055] Authentication method 321 can indicate an authentication method that is 
mutually supported at client side 350 and server side 360. Trust anchor 322 can be a trust 
anchor as previously described. 

[0056] When client side 350 is re-authenticating with server side 360 (e.g., 
authenticating some time after a negotiation), server request 313 can alternately include re- 
authentication encrypted 328. Re-authentication encrypted content can include 
authentication signature 329 and identity certificate 331. Authentication signature 329 can 
include a signature ID type (e.g., SHA-1 (key ID length = 20 octets) or SHA256 (key ID 
length = 32 octets)), a signature key ID, and a signature type (e.g., HMAC, RSA PKCS #1, 
RSA PSS, or DSA). Identity certificate 331 can include, for example, an X.509 certificate, a 
Kerberos token, a WS-Security token, a Raw Public Key, a hash and URL or an X.509 
certificate, a hash and URL of a WS-Security token, a hash and URL of a raw public key. 
[0057] In should be understood that other types of encrypted authentication content 
(instead of negotiation encrypted content 318 or re-authentication encrypted content 328) 
can alternately be included in server request 313. For example, when bootstrapping a client 
using an existing username and password, server request 313 may have encrypted content 
including an authentication signature, an identity certificate, and an authentication method. 
[0058] When bootstrapping a new client with an X.509 certificate, server request 313 
may have encrypted content including a challenge, a trust anchor, an authentication method, 
and an enrollment request. An enrollment request can include a request type (e.g., Kerberos 

- Page 19 - Docket No. 13768.497 



TGT request, Kerberos AS request, PCKS #10 request, or CMC request), a key type (e.g., 
RSA signature, DSA, ECDSA, or DH + ECDH), a key sub-type (e.g., PSA signature keys or 
DH + ECDH keys) and a key size (e.g., 1024 bits). When authenticating with an X.509 
certificate, request 313 may have encrypted content including an authentication signature, an 
identity certificate, and an authentication method. 

[0059] When bootstrapping a new client with a Kerberos ticket, server request 313 may 
have encrypted content including a challenge and an enrollment request. 
[0060] In response to server request 313, client side 350 can send client response 332. 
Client response 332 can include previous packet ID 333 and data responsive to encrypted 
content included in server request 313. Previous packet ID 333 can indicate the packet ID 
corresponding to server request 313. When client side 350 and server side 360 are 
performing a negotiation, client response 332 can included encrypted response 334 
(encrypted with the tunnel key). Encrypted response 334 can be a response to challenge 
319. 

[0061] Client side 350 can generate an appropriate response to challenge 319. For 
example, an appropriate response can be the HMAC of the challenge 119 using a shared 
secret. An appropriate response can be configured according to the following formula: 

Response c = HMAC SS [Challenge] 
[0062] When client side 350 is re-authenticating with server side 360, client response 
332 can include authentication signature 336. 

[0063] It should be understood that other types of data responsive to encrypted 
authentication content (instead of encrypted response 334 or authentication signature 336) 
can alternately be included in client response 332. For example, when bootstrapping a 
client using an existing username and password, client response 332 can have encrypted 
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responsive data including a challenge, an end-user identity payload, and a domain identity 
payload. End-user identity payloads and domain identity payloads can include a name type 
(e.g., fully qualified DNS name, am e-mail address, an IPv4 address, and IPv6 address, a 
DER encoded X.500 distinguished name, or a realm name). 

[0064] When bootstrapping a new client with an X.509 certificate, client response 332 
can have encrypted responsive data including a response and a certificate request. When 
authenticating with an X.509 certificate, client response 332 may have encrypted responsive 
data including an authentication signature and an identity certificate. When bootstrapping a 
new client with a Kerberos ticket, client response 332 may have encrypted responsive data 
including a response and a certificate request. 

[0065] Embodiments of the present invention facilitate the negotiating authentication 
mechanisms from among a number of different authentication mechanisms. Client 
computing systems and server computing systems can identify mutually supported 
authentication mechanisms and use identified mechanisms for authentication. Automated 
negotiation relieves a user from having to be aware of authentication mechanisms that may 
be deployed for a network. Accordingly, authentication can be performed more efficiently. 
[0066] Figure 4 and the following discussion are intended to provide a brief, general 
description of a suitable computing environment in which the invention may be 
implemented. Although not required, the invention will be described in the general context 
of computer-executable instructions, such as program modules, being executed by computer 
systems. Generally, program modules include routines, programs, objects, components, data 
structures, and the like, which perform particular tasks or implement particular abstract data 
types. Computer-executable instructions, associated data structures, and program modules 
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represent examples of the program code means for executing acts of the methods disclosed 
herein. 

[0067] With reference to Figure 4, an example system for implementing the invention 
includes a general-purpose computing device in the form of computer system 420, including 
a processing unit 421, a system memory 422, and a system bus 423 that couples various 
system components including the system memory 422 to the processing unit 421. 
Processing unit 421 can execute computer-executable instructions designed to implement 
features of computer system 420, including features of the present invention. The system 
bus 423 may be any of several types of bus structures including a memory bus or memory 
controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The 
system memory includes read only memory ("ROM") 424 and random access memory 
("RAM") 425. A basic input/output system ("BIOS") 426, containing the basic routines that 
help transfer information between elements within computer system 420, such as during 
start-up, may be stored in ROM 424. . 

[0068] The computer system 420 may also include magnetic hard disk drive 427 for 
reading from and writing to magnetic hard disk 439, magnetic disk drive 428 for reading 

gj from or writing to removable magnetic disk 429, and optical disk drive 430 for reading from 
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w 2§ < I i a or wr iting to removable optical disk 431, such as, or example, a CD-ROM or other optical 
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Z^<5> media. The magnetic hard disk drive 427, magnetic disk drive 428, and optical disk drive 
§ I £ S 1 5 430 are connected to the system bus 423 by hard disk drive interface 432, magnetic disk 
^ " drive-interface 433, and optical drive interface 434, respectively. The drives and their 

associated computer-readable media provide nonvolatile storage of computer-executable 
instructions, data structures, program modules, and other data for the computer system 420. 
Although the example environment described herein employs magnetic hard disk 439, 
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removable magnetic disk 429 and removable optical disk 431, other types of computer- 
readable media for storing data can be used, including magnetic cassettes, flash memory 
cards, digital versatile disks, Bernoulli cartridges, RAMs, ROMs, and the like. Storage 132 
may be a portion of one of the described types of computer-readable media. 
[0069] Program code means comprising one or more program modules may be stored on 
hard disk 439, magnetic disk 429, optical disk 431, ROM 424 or RAM 425, including an 
operating system 435, one or more application programs 436, other program modules 437, 
and program data 438. A user may enter commands and information into computer system 
420 through keyboard 440, pointing device 442, or other input devices (not shown), such as, 
for example, a microphone, joy stick, game pad, scanner, or the like. These and other input 
devices can be connected to the processing unit 421 through input/output interface 446 
coupled to system bus 423. Input/output interface 446 logically represents any of a wide 
variety of possible interfaces, such as, for example, a serial port interface, a PS/2 interface, a 
parallel port interface, a Universal Serial Bus ("USB") interface, or an Institute of Electrical 
and Electronics Engineers ("IEEE") 1394 interface (i.e., a Fire Wire interface), or may even 
logically represent a combination of different interfaces. 

[0070] A monitor 447 or other display device is also connected to system bus 423 via 
video interface 448. Monitor 447 can display monochrome and/or color graphical objects, 
including text, generated by computer system 420. Other peripheral devices (not shown), 
such as, for example, speakers, printers, and scanners, can also be connected to computer 
system 420. Printers connected to computer system 447 can print monochrome and/or color 
graphical objects, including text, generated by computer system 420. 

[0071] Computer system 420 is connectable to networks, such as, for example, an 
office-wide or enterprise-wide computer network, a home network, an intranet, and/or the 
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Internet. Computer system 420 can exchange data with external sources, such as, for 
example, remote computer systems, remote applications, and/or remote databases over such 
networks. 

[0072] Computer system 420 includes network interface 453, through which computer 
system 420 receives data from external sources and/or transmits data to external sources. As 
depicted in Figure 4, network interface 453 facilitates the exchange of data with remote 
computer system 483 via link 451. Network interface 453 can logically represent one or 
more software and/or hardware modules, such as, for example, a network interface card and 
corresponding Network Driver Interface Specification ("NDIS") stack. Link 451 represents 
a portion of a network (e.g., an Ethernet segment), and remote computer system 483 
represents a node of the network. 

[0073] Likewise, computer system 420 includes input/output interface 446, through 
which computer system 420 receives data from external sources and/or transmits data to 
external sources. Input/output interface 446 is coupled to modem 454 (e.g., a standard 
modem, a cable modem, or digital subscriber line ("DSL") modem), through which 
computer system 420 receives data from and/or transmits data to external sources. As 
depicted in Figure 4, input/output interface 446 and modem 454 facilitate the exchange of 
data with remote computer system 493 via link 452. Link 452 represents a portion of a 
network and remote computer system 493 represents a node of the network. 
[0074] While Figure 4 represents a suitable operating environment for the present 
invention, the principles of the present invention may be employed in any system that is 
capable of, with suitable modification if necessary, implementing the principles of the 
present invention. The environment illustrated in Figure 4 is illustrative only and by no 
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means represents even a small portion of the wide variety of environments in which the 
principles of the present invention may be implemented. 

[0075] In accordance with the present invention, modules, such as, for example, 
credential provisioning module 112 as well as associated program data, such as, for 
example, limited-use credential 102, key pairs 103 and 113, server requests 301 and 313, 
and client responses 306 and 332, can be stored and accessed from any of the computer- 
readable media associated with computer system 420. For example, portions of such 
modules and portions of associated program data may be included in operating system 435, 
application programs 436, program modules 437 and/or program data 438, for storage in 
system memory 422. 

[0076] When a mass storage device, such as, for example, magnetic hard disk 439, is 
coupled to computer system 420, such modules and associated program data may also be 
stored in the mass storage device. In a networked environment, program modules depicted 
relative to computer system 420, or portions thereof, can be stored in remote memory 
storage devices, such as, system memory and/or mass storage devices associated with 
remote computer system 483 and/or remote computer system 493. Execution of such 
c4 modules may be performed in a distributed environment. 
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§ ^ t S 2 3 in all respects only as illustrative and not restrictive. The scope of the invention is, 
^ therefore, indicated by the appended claims rather than by the foregoing description. All 

changes, which come within the meaning and range of equivalency of the claims, are to be 

embraced within their scope. 

[0078] What is claimed and desired secured by United States Letters Patent is: 
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